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Abstract 

In this paper we lay out the design time and space of component assembly in a visual builder, 
and propose concrete ways of also handling context components seamlessly. We present an envi- 
ronment that allows Java developers to rest and evaluate JavaBeans components implementing the 
extensible runtime containment and services protocol We enhanced the BeasxBoxfrom the Bean 
Development Kit (BDK) with new visual manipulation capabilities for nested beans, so that It is 
possible to drag and drop, serialize and de-seriaiize, group and ungrvup, nested beans. By means 
of these visual manipulations, child beans can be visually put inside context beans. 

1. Introduction 

Glasgow (8), Sun's code -name for the new release of the JavaBeans [10} component model 
specification, lists the extensible runtime containment and services protocol [1] as one of three 
new capabilities added to the JavaBeans component model (the other two are the drag and drop 
subsystem for the Java foundation classes [2] and the JavaBeans activation framework f 3J). This 
capability is manifested in Java 2 (JDK 1.2) in a new java .beans .beancontext package. 
Components implementing the BeanContext Chi Id interface may interrogate their enclosing 
BeanContext environment to dynamically discover and employ services. 

The precise details of implementation, however, remain complicated. Much of the complexity of 
putting the newly introduced context package into use rises from the possibility of the component 
to simultaneously belong to more than one of the three different logical hierarchies: a collection 
hierarchy, a visual hierarchy, and the new context hierarchy. Moreover, each hierarchy is governed 
by a different, sometimes contradictory, set of constraints and rules. For example, a Container 
cannot implement a BeanContext interface directly [1], but may be associated with one by im- 
plementing die BeanContext Proxy interface, all because of a method name collision. 

The BeanContext specification and API alone are insufficient for utilizing the new concepts 
quickly: the documentation is inconclusive, complicated to understand and open io interpretation. 
The new j a va . beans . beane on text package is an API, not a set of guidelines, and the overall 
learning curve remains steep (12). Unfortunately, die JavaBeans tradition of providing a testing 
environment along with the API was not followed. 

Unlocking the JavaBeans API and its underlying philosophy would have been hard without the 
availability of the Bean Development Kit (BDK) [9J, also called BaanBox [7] after the name of 
its main class. The BeanBox permits running JavaBeans demos, and testing your own beans. It 
demonstrates the functionality expected from a visual builder. It's loyal to the specification. One 
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can determine, for example, whether a reluctant bean is really not working properly, or whether the 
commercial environment is at fault, by also testing the bean in the BeanBox. It is not a complete 
development tool, but rather a testing and demo tool 

What is missing is a similar lightweight dcrao, assembly, design, and testing environment, tike 
the BDK, but one that also supports context-nested beans. Such an environment would serve three 
purposes; it would provide: (1) a vehicle for demonstrating good examples of runtime discovering 
of services; (2) a third-party client for testing user-made context components; and (3) a prototype 
(but not necessarily the Holy Grail) for visual bean-builder environments. As far as we know, 
none of the commercial JavaBeans builders fully support the new runtime containment and services 
protocol [1], 

In this paper, we identity the lifetimes and visual dimensions of components at assembly and de- 
sign time, we lay out the assembly-design space, and we explain what is needed in order to provide 
a meaningful assembly and design environment for manipulating and nesting context components. 

We present an environment, which we name CantexsBax (13], for demonstrating, testing, or 
prototyping a visual context bean-builder. ContextBox is an extension of JavaSoft's BeanBox. 
It adds to the BeanBox several new features that are useful for the developers and programmers 
working with BeanContext objects. ContextBox was created as a byproduct of our need to 
quickly test our own beans that implement the BeanContext interface, and now we wish to share 
it with everyone. 

In Section 2, we explain the fundamental terms and concepts, and in Section 3, we then de- 
scribe the additional features required for assembling context components at design-time. Section 4 
describes the enhancements to the BeanBox: new visual manipulation capabilities, so that it is 
possible to drag and drop, serialize and de-serialize, group and ungroup nested beans. By means of 
these visual manipulations, beans can be put inside other beans. In Section 5, we conclude and talk 
about future work. 

1.L Related work 

JavaSoft's BeanBox was used as a base because it is platform independent, supports Java 2, 
already had some support (although limited) for the BeanContex t interface, and most important, 
because its source code was available. 

Prototyping a new tool by reusing the BeanBox source code seems to be a common practice. 
Wang and Mac Lean [21] enhanced the BeanBox to support introspection features that assist in 
component assembly using HOP links based on IONA Orbix Web Miller et af. created a simulation 
environment called JSIM [15]. The BeanBox source code is incorporated inside the impressive 
Sieve [6] collaborative visualization environment. Natarajan and Ro&enbfum [16] nave extended 
the BeanBox to support events in the CI architecture style {19]. Occasionally, implementation 
details about the internal working of the BeanBox are sought in the comp.tang.javabtans news 
group. 

However, these are all examples of special purpose extensions. In comparison, this work may 
be seen as a general-purpose extension: extending the BDK to support the new standard runtime 
containment and services protocol. Moreover, this work also uncovers the internal working of the 
BeanBox and documents the information needed for reusing it, information that might be helpful 
for authors of future BeanBox extensions. 

The BDK is platform independent, and it is lightweight with no special requirements. Its intent 
is testing, not production. Its approach is rannable design time (unlike other tools which build, 
generate code, and then run.) Thus, it reacts faster than similar tools. It is, therefore, a suitable 
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platform far fulfilling our purpose: testing context components and demonstrating how a supportive 
builder works. 

JavaSoft explains how to work with the BeanBox Kit [7]. Sun provides the source code, and 
encourages users to "play with it" There is some documentation within the code. However, there is 
no documentation about the design of the BeanBox. Even the projects listed above do not report a 
whole lot about the internal design of the BeanBox. Hopefully, our work can provide a jump-start 
to those who are attempting to reuse the BDK source code. 

2* Understanding the assembly-design space 

A seamless introduction of new features requires, first of all, understanding the design and phi- 
losophy behind existing ones. In this section we lay out the design space and define the fundamental 
terms. First, we explain the distinction between assembly and design lime in the component's life- 
cyck. Then, we explain the difference between the vi&oalhy, symbolic-representation, and visibility 
of a component Finally, we explain in these terms the behavior of existing visual bean-builder en- 
vironments. 

2X Lifetimes of a component 

Components change form and appearance during their normal development and lifetime. We 
identify four lifetimes: (1) compile time — the embryonic stage of the component; (2) and (3) 
assembly time and design rime— two periods of metamorphosis sometimes referred to as ont — 
building-time; (4) runtime — component maturity. 

The definitions of the first and last lifetimes are standard [18]: 

Compile time: the time when the component's, source code is compiled into byte code and "for- 
gotten" thereafter. Typically done by third party component providers. That is, a component 
may originate from a different author in binary formal and without its source code. 

Runtime; the time when the application, which is built out of components, is executed. 

The explicit distinction between assembly and design time is non-traditional, but one of impor- 
tance, because often the fine line between the two environments is somewhat blurred. Since these 
may overlap or be interleaved, it is clearer sometimes to refer to them as activities rather than times. 

Assembly: the activity of connecting. At assembly time the application (or component) is assem- 
bled from other (compiled) components. The activity takes place between the compilation of 
the components and the compilation (or serialization) of the application. 

Design: the activity of specifying the took and feel of the application. At design time/ the com- 
ponents' visual aspects are displayed, permitting a user-friendly mechanism for fine-tuning 
the application's look, feel, and behavior. In this activity, the programmer can also test the 
application. 

2J. Vfsualtty,symrwli^ofcomp 

A component can be visual or non-visual, may or may not be associated with an icon (a symbolic 
image), and at times may be visible or invisible. 

• VfcuaUty A JavaBeans component may be visual or non-visual A visual component can be 
displayed visually (le., made visible) in the final application. Visual beans are the most com- 
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mon kind. This is a natural consequence of the example set by Sun: the first beans were all 
GUI components, namely AWT components. JavaSoft even initially defined JavaBeans com- 
ponents to be "reusable software components mat can be manipulated visually in a builder 
tool" [10). However, beans may also be non-visual. Non-visual beans are useful for their 
functionality despite not having a visual appearance. For example, an adapter between two 
components is very useful but need not be displayed visually in the final application. 
Symbolism Some components arc associated with a symbolic image, an icon, others are 
assigned one by the system, eg., a label For a JavaBeans component, the icon is specified 
by the bean author in the Beanlnf o adjunct class. For a bean without an icon, the system 
instantiates a Label and uses it like an icon. The icon or label is used to display the list of 
available components (in the ToolBox window) when a jar is loaded The icon or label is 
also used to visually display non-visual beans at assembly time. 

Visibility A JavaBeans component can be visible or invisible. Visibility is different than 
vbuality. Visibility is the degree of being visible. It is possible to see visible beans. Invisible 
beans arc hidden from the eye. Visuamy. on the other band, is the ability of being visual 
{at runtime). A visual bean is associated with a java . awt . Component object, which is 
displayed (at design time), regardless of whether or not it is associated with an icon. A non- 
visual bean is represented visually (at assembly time) by its icon, and if it does not have one, 
by a system generated label. But even visual beans can be at times invisible, e.g., by invoking 
setVisible { false > (at either design or runtime). 1 

23. Assembly and design environments 

Different industrial JavaBeans visual bean-builder environments have taken different approaches 
on how to provide the user with assembly and design time control. 

• Two-window approach. Sun's JavaStudio [1 1] displays two windows simultaneously. One 
window shows the assembly picture while the other the design of the application. The win- 
dows are fully synchronized. The assembly window shows ail beans by then* icon repre- 
sentation with in- and out-ports, permitting the users to connect an out-port to some other 
in-port The design window shows only visual beans in their visual representation, and hides 
the connections. Thus the design window shows how the application would look at runtime. 
Moreover, the design window is an active running application, allowing the application to be 
tested immediately. For example, you can enter text into a Text Field component, push a 
Button component, examine the reaction to mouse-movements, and so on. 

• Split-window approach. IBM VisualAge for Java [5] displays only one window. But, within 
the displayed window, a dashed line denotes a special design region. You can create visual 
beans only in that region, and non-visual beans only outside that region. However, you can 
pull the connectors (wires) across the (dashed lines) borders, because the two regions are 
practically parts of a single window. Unlike JavaStudio, the design region is inactive. To test 
the application, the system must generate code, eg., an applet* and compile and tun it, a time 
consuming procedure. 

• Mode-toggHng approach. In Sun's Beanfiox [9], assembly and design are one and the 
same. This is because the BeanBox tool kk is not meant to be a development tool, but 
rather a "proof of concept** It Is a demo, testing, and prototype tool: it demonstrates the 

'The method j aVa . avt . Component . aetvislble (boolean b) replaces the deprecated methods h ide < > 
ndahowO. 
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working of beans, il tests user-created beans, and it is a prototype that serves as an elaborated 
specification for industrial visual tools providers. 

In BeanBox 1.1 , the user can switch back and forth from a runtime to a design time view by 
toggling two environment options: 

1. Enable/disable design mode. Design mode is enabled by default When design mode 
is disabled, the BeanBox displays and behaves like the produced application would at 
runtime. This runtime mode is useful for testing the designed application without the 
extra BeanBox functionality as a developing tool. In disabled mode, the panel showing • 
available beans is hidden. Selecting a component does not activate introspection, expose 
properties, or bring up customization panels; and all non- visual beans disappear As a 
result, the application response time improves drastically. 

2. Show/hide Invisible beans. This is a misnomer, 2 as it really means show or hide non- 
visual beans. When a non-visual bean is added to the BeanBox container, a label with 
its name is displayed. Otherwise, the user would not see the newly added bean and 
would not be able to customize its properties or connect it with other beans. Hiding 
invisible beans makes all non-visual beans invisible (even in design mode). This is 
intended to provide the user with a view of how the final design would look like, and 
still permit fine-tuning the visual beanfc that remain visible. 

Four combinations are hence possible in the mode-toggling approach: 

- Enable design; show non-visual: assembly and execution only. 

- Enable design; hide non-visual: design and execution only. 

- Disable design; show non-visual: A "reaoVonly" view of assembly mode. 

- Disable design; hide non-visual: execution only (runtime). ■ 

In the next section we describe how new support for the runtime containment and services pro- 
tocol can be seamlessly added to the assembly and design environment 

3. Manipulation and representation of BeanContext components 

The essence of the extensible runtime containment and services protocol [1} is that (Bean- 
Context) beans may be placed in (and removed from) their enclosing BeanContext bean. The 
BeanContext hence becomes a container of objects, which not only introduces a new logical 
hierarchical structure, but also provides to its inhabitants a service discovery (and obtaining) proto- 
col. 

In order to test beans implementing the BeanContext interface in a visual development envi- 
ronment, the beans need to have some kind of visual representation. Without such a representation, 
it would be impossible to manipulate them visually at assembly and design time. Several difficul- 
ties arise. When a new BeanContext component (or a proxy for one) is added to the BeanBox 
there is the question of how to represent that bean visually. The visual representation can be pro- 
vided either by the bean author or by the development environment Moreover, the bean can be a 
BeanContext Proxy and itself a visual composite (extends Java . awt . Container). In that 
case, there are two hierarchies to maintain and a possibility for inconsistency between the two. 

'If die bean i* already invisible why the need to hkte ii? 
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The BeanBox distinguishes (when visual representation is concerned) only between visual 
beans (which are a kind of j ava . awt .Component) and non-visual ones. A non-visual bean is 
represented by a special label object (an instance of sun . beanbox . Our Label ), which displays 
the bean's name. When hide invisible beans mode is selected or design mode is disabled, the labels 
representing non- visual beans are hidden. When enhancing the BeanBox with support for runtime 
containment and services protocol, there is also the BeanContext or BeanContextProxy. 
case to consider, and alt possible combinations of the visual and context cases. 

Every bean can have a Component or Container, and/or a BeanContext* associated 
with it. A bean can establish that relationship either through inheritance by extending one of 
BeanContext, Component or Container classes, or by being a BeanContextProxy or 
a BeanContextContainerProxy or a BeanContextChildConponentProxy for that 
object 3 

More abstractly, in terms of the Composite design pattern [4], a visual component is either a 
visual leaf or a visual composite. A visual composite, or a visual component, is any instance of 
a class extending the abstract class Container, or the abstract class Component, respectively. 
A visual leaf is a Component that is not a Container. Being a visual composite but not a 
visual component is impossible, since Container extends Cotnponent. as with the design pat- 
tern. Similarly, a context component is either a context leaf or a context composite. Prom a visual 
perspective, however, a context leaf and a components not associated with a context are treated 
the same. There are therefore only 6 combinations to consider: {non-visual.visual-leaf , visual- 
composite} x{ context leaf ^mext-compoaite}. For each we offer a different policy for the visual 
representation: 

1 . A non-visual context leaf, the original BeanBox covers the case of a bean which is neither 
a Component not a BeanContext. At assembly time, a special label represents a non- 
visual bean, which is hidden at design/runtime mode. No beans can be placed inside this - 
bean. - 

2. Both a visual and a context leaf. A bean, which is a Component but not a BeanContext, 
should always be represented (in assembly time, design time, and runtime) by the Compo- 
nent itself This behavior would be consistent with the behavior in the original BeanBox. 
No beans can be placed inside this bean. It is neither a visual nor a context composite, and 
therefore its visual representation should be used at all times. 

3. A visual composite context lest A bean, which U a Container but not a BeanContext, 
is a common case, typically coded by a user who did not anticipate runtime containment This 
kind of visual bean should always represent itself visually. Still, there is a catch. If (he user 
places inside this bean other beans that expect services from a runtime environment, then 
those beans must be added to that container and also to the runtime context of some other 
bean. 

Even i f it were possible to somehow manage this split behavior, it would still be too confusing 
to work with. Therefore, in the extended BeanBox version, every bean that is a container 
but not a BeanContext is automatically associated with a new BeanContext. Then, 
every bean added to mat container is also added to its associated BeanContext, which 
propagates the environment services according to the protocol. 

4. A non-visual context composite, This is a kind of BeanContext bean that has no visual 

3 Cowponent uA Container arc time* from Ifae jftva.avt package. Tbc often tre alt ctov* from the 
j ava . bean* . be&neon tex t package. 



301 



representation. It should be represented by a special kind of Container (e.g., Trans- 
paren tPanel). In assembly time, the user can place inside this bean other beans, and in 
design/runtime the container should become "transparent", i.e., become itself invisible but 
leave the contained components visible. 

5. A visual leaf context composite. A bean can be both a Component and a Beancont ext . 
However, this is an unnatural case that probably ought to be disallowed. It is unnatural 
because the bean seems to have a contradictory behavior, i.e., as a leaf (Component) in 
the visual containment hierarchy, and as a composite, a collection (BeanContext), in the 
Be&nOontext containment hierarchy. 

A possible work-around is to represent such beans at assembly time by a special kind of 
Container (e.g.» OurPanel, analogous to Our Label), which will allow the user to 
visually put in it child beans, and at design/runtime by the Component associated with the 
bean. Beans placed inside this bean should be added to its associated container and also to 
its BeanContext. 

6. Both a visual and a context composite. This is a bean that is a Container and a Bean- 
cont ext. It is me simplest case. The bean should always represent itself, and there are 
no additional problems. Beans placed inside the component should be added to both the 
Container and to the BeanContext, other by the bean itself or by die environment 

4. BeanBox enhancements 

To demonstrate the approach described in the previous section for design-time assembly of 
BeanContext components, we enhanced JavaSoft's BeanBox from BDK 1 .1 (9] with the new 
visual manipulation capabilities for nested beans. Focusing on the most salient features we list here 
6 visual enhancements: hierarchical visual containment, hierarchical context containment, drag and 
drop capabilities, de-serializing, grouping and ungrouptng nested beans, and removing wrappers. 
By means of these visual manipulations beans can be put inside context beans. 

4.1. Hierarchical visual cont&huxtent 

It Is difficult to imagine the context hierarchy unless a corresponding visual containment hierar- 
chy displays it Therefore, the first step is to add the ability to display nesting of visual containers. 

The BeanBox class is a visual composite; consequently, when adding new beans, one can place 
the new bean inside the panel. In the standard BeanBox, however, it is impossible to place a new 
bean inside another visual composite, which might be itself inside the BeanBox and displayed on 
the screen. By fixing this discrimination, our extension permits new beans to be created and placed 
inside any AWT container. As a result one can form nested visual components. 

4*2. Extensible runtime containment and service protocol support 

Once the support for presenting a visual hierarchy is in place, the next step is to support the 
runtime containment protocol. Sun's BeanBox already has a limited support for the extensible 
containment and services protocol [1]. The BeanBox implements the BeanContext Proxy 
interface. A new bean added to the BeanBox container is automatically added also to the Bean- 
Context peer; the BeanContext for which the BeanBox container is a proxy. Now that we 
have added the ability to place beans inside any visual composite, we need also to take cafe of 
adding the new bean to its innermost bean context 
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the innermost context of a bean is not necessarily the BeanBox, but rather a BeanContext 
associated with the container to which the bean is added. Unfortunately, the BeanBox is totally 
ignorant of the existence of any other BeanContext component in the environment 

As a result, one can only test beans against the BeanContext for which the BeanBox object is 
a proxy. 4 While this capability is useful it is very limited In particular, one can test one's services 
beans but one cannot test one's own BeanContext beans. 

This second extension provides users with the possibility of testing their own BeanContext 
beans. When a bean is created inside a nested container, the innermost context is located, and the 
bean is added to it. - 

43. Drag and drop 

After adding the first two features, the enhanced BeanBox has already become a useful testing 
tool. However, there are still several problems that make the developer's life harder than ought to 
be. What if a bean, in its initial state, cannot be placed directly into some BeanContext, but 
could be if it were customized? There is no way to customize a bean before creating it One can 
place a bean in the BeanBox panel and customize it there. However, so tar there is no support for 
moving beans from one container into another. 

Now that we may have more than one container, it is natural to want to be able to move items 
from one context to another. The BDK supports moving, but because the assumption is that there 
is only one container, namely the BeanBox, moving is interpreted as just changing the position in 
the same container. The fourth extension adds support for drag-and-drop moving that is sensitive 
to the underlying container's context Recall mat the BeanBox is a BeanContext Proxy and 
hence both a visual and a context composite. With the drag-and-drop capability one can customize 
the bean in the BeanBox and then drag it into some other container. 

Another reason for a drag-and-drop feature is to save development time. If a user by mistake 
places a bean in the wrong container, the only way to undo it in the standard BeanBox is to delete 
(cut) the bean and add a new one again. With the new drag-and-drop capability, the user can move 
the bean into the correct container. 

4.4. De-serlalization 

In the BeanBox, there is a feature, named Serialize bean, that allows the user to dump a bean's 
state to a file. There isn't, however, any way to read back in the bean's state from the saved Ale (to 
de-serialize a bean). It Is interesting that many more complicated features were implemented (eg., 
making an applet from the BeanBox), but not this simple one. We have added this capability. 

4.5. Grouping and ungroupiug 

There ts no way to manipulate subcomponents of beans (e.g>, customize, hook events up, bind 
properties), not even if the bean is a Container. For example, a bean that extends Panel and 
contains a button would not permit the programmer to select the button. As a result, one cannot 
change the button's label or color, or connect its Ac tionBvent to some other bean. 

The fifth enhancement is the ability to manipulate subcomponents by ungrouping the bean. Un- 
grouping beans allows the programmer to separately manipulate each subcomponent in that bean. 

*n* BoanBox is provided widi two examples showing the working of the BeanContext: the Me thodTrac lno 
and the Info Bus services, but these cannot be changed. 
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The opposite operation is grouping. Once the bean and its subcomponent* are customized, the user 
can it-group the beans. Grouping also disables any additional objects that are used internally by 
the BeanBox for manipulating beans (like wrappers). 

4,6. Removing Wrappers from the visual hierarchy 

The last enhancement is crucial for managing AWT and BeanCont ext hierarchies, since beans ' 
could be sensitive to their enclosing BeanContext environment (and contrariwise). In the stan- 
dard BDK, every bean is automatically placed in a Wrapper (a kind of Panel) before being added 
to the BeanBox. The only function of the wrapper objects in the visual presentation of beans is to 
draw a hashed bar around selected ones. The wrapper, however, can contuse a BeanContext to 
reject an otherwise acceptable bean. As a result, certain context-sensitive beans can be tested only 
by removing the additional layer of wrappers. 

5. Conclusions and future work 
In ftis paper we bad two objectives: 

1. To present a better understanding of the design time and space of component assembly in a 
visual builder. 

2. To present the new ContextBox too!, which enhances the BeanBox from Sun by adding the 
ability to also manipulate beans internetting the BeanContext interface. 

The first objective is useful in understanding other software component models p4, 17, 19, 
20], while the second is strongly related to the JavaBeans technology. Design and implementation 
issues, which , were omitted due to space limitation, can be found in further detail in (13}. These 
may be of help to others who wish to create enhancements of their own. 

Our ContexiBox is a strict extension of the BeanBox- However, during our exhaustive use of 
the BeanBox, we have occasionally encountered some odd system behavior. Only those which 
were surely caused by bugs and could not be interpreted as undocumented features have been fixed 
in the ContextBox version. As with any software program, ContextBox is far from perfect. There is 
always room for improvement, both in the existing features and in the new added features. 

Some ideas for future enhancements are to allow the user to disconnect connected beans, to 
provide more complex event hookups, and to visually show connections during design time. The 
first enhancement would save a lot of testing time. Wrongly connected beans would not have to be 
erased and connected all over again. Instead, only wrong connections could be undone. The second 
enhancement could be very handy for more complicated tests, e.g., when the user loses track which 
beans are connected to where, in the middle of (he connecting process. Alt these features are not 
necessarily related to the BeanContext beans, but are also very important for making the BDK 
more accessible and thus useful. 

The BeanContext specification leaves a few issues open. For example, when a Bean- 
Cont extCbild is associated with a Cotaponent and a BeanContext with a Container, it 
is not clear how they should interact The specification gives three possible models and is there- 
fore not conclusive enough. This makes the life of a too) designer difficult The ContextBox, as a 
prototype, can be of help here too. 
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